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EXECUTIVE  SUMMARY 
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Acquisition  of  computer  systems  for  the  NORAD  Command 
Post  at  Cheyenne  Mountain  has  been  problematic  throughout  its 
entire  history.  The  acquisitions  have  been  characterized  by 
unrealistic  specifications,  budget  overruns,  slipping  schedules 
and  ill-defined  responsibility  in  each  of  the  three  historical 
programs — NOCOPS,  427M  and  the  Cheyenne  Mountain  Upgrades.  When 
problems  were  encountered  in  each  of  these  phases,  intervention 
by  high  command  levels  was  necessary  in  order  to  achieve 
operational  capability.  An  historical  study  of  these  problems 
and  solutions  leads  to  principles  which  were  shown  to  work  in 
the  Granite  Sentry  Program,  and  which  should  be  required  in 
future  Cheyenne  Mountain  acquisitions.  <^r - 
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BIOGRAPHICAL  SKETCH 

Having  been  involved  with  Cheyenne  Mountain  computer 
systems  at  various  times  -from  1972  through  1989,  the  author 
brings  a  unique  set  of  experiences  to  bear  on  the  analysis  of 
the  Cheyenne  Mountain  acquisitions.  From  1972-1975,  as  an 
orbital  analyst  in  the  NORAD  Space  Defense  Center,  the  authc.- 
gained  operational  experience  as  a  user  of  the  original  NORAD 
Combat  Operations  Program  Systems.  From  1975-1977,  he  obtained 
through  the  Air  Force  Institute  of  Technology  a  Master's  Degree 
in  Computer  Science  from  the  University  of  Texas  at  Austin. 

From  1977-1985,  as  a  computer  software  project  manager,  he 
monitored  the  implementation  of  the  427M  system,  and  he  was 
involved  with  upgrades  to  radar  and  optical  systems  which 
interface  to  NORAD.  From  1986-1987,  at  HD  AFSPACECOM,  he  was 
the  branch  chief  over  the  development  of  CSSR  and  CCPDSR. 
Finally,  from  1987-1989,  the  author  was  the  project  leader  for 
the  AFSPACECOM  Granite  Sentry  Development  Office.  Thus,  the 
author  has  had  the  opportunity  for  over  17  years  to  observe 
various  phases  of  the  development  and  implementation  of  the 
increasingly  complicated  Cheyenne  Mountain  computer  support 
systems. 
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my  wife  and  children  who  continually  interrupted  me  (with 
encouragement)  while  I  was  writing.  Without  them  it  would  not 


have  been  worth  the  effort. 


PREFACE 


Over  the  last  17  years-,  my  service  career  has  provided 
me  with  direct,  personal  experience  with  all  three  of  the  major 
phases  of  the  NQRAD  computer  systems.  As  a  user  in  the  original 
NORAD  Combat  Operations  and  Space  Defense  <425L/496L)  system,  I 
witnessed  the  difficult  implementation  of  its  replacement,  the 
427M  system.  After  the  notorious  false  events  of  1979  and  19E0, 
I  was  a  low  level  participant  in  the  investigation  team  which 
recommended  improvement  of  test  control  procedures. 

For  six  years  of  working  on  programs  which  interfaced 
with  the  427M  system,  I  observed  the  Cheyenne  Mountain  Upgrades. 
For  6  months  in  1986,  I  supervised  the  harassed  AFSPACECOM 
managers  who  simultaneously  were  attempting  to  get  the  CSSR 
Block  I  on  line,  were  answering  GAO  complaints,  and  were 
assisting  their  Electronic  Systems  Division  counterparts  in 
getting  the  CSSR  Block  II  on  contract.  During  that  time,  we 
discovered  that  no  one  possessed  a  complete  copy  of  the  CSSR 
specifications — not  even  the  contractor  who  was  bidding  an  old 
specification.  Requirements  for  the  replacement  system  could 
not  be  articulated  because  the  user  who  specified  them  could  not 
be  identified.  By  August  1986,  Cheyenne  Mountain  programs  were 
a  source  of  frustration  to  all  interested  parties. 


Soon  after  it  was  established,  the  Air  Force  Space 
Command  was  directed  to  accomplish  Granite  Sentry  on  time, 
within  budget,  and  by  ourselves  if  necessary.  I  was  placed  in 
authority  over  that  program  and  was  tasked  along  with  Lieutenant 
Colonel  Pete  Maravelias  and  Captain  Steve  Shively  to  work  out  a 
plan  that  would  be  successful.  Fortunately,  we  had  the  devoted 
help  of  Major  Generals  Spraker,  Brandt,  Cassity,  and  Clark  as 
well  as  then  Colonel  Gray.  Their  interaction,  insight,  and 
foresight  forged  the  agreement  which  allowed  Granite  Sentry 
Phase  I  to  reach  operational  capability. 

These  personal  experiences  have  led  me  to  investigate 
the  historical  environment  of  Cheyenne  Mountain  in  an  effort  to 
understand  the  factors  which  have  made  the  development  of 
computer  systems  for  the  mission  so  difficult.  Valuable 
insights  into  these  problems  have  been  made  at  each  stage  of 
the  acquisitions.  It  is  my  hope  that  these  principles  may  be 
used  to  formulate  a  model  for  successful  future  acquisitions. 

Acknowledgment:  A  special  gratitude  is  due  my  brother  Patrick 

who  was  a  tireless  editor. 
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CHAPTER  I 


INTRODUCTION 

The  North  American  Aerospace  Defense  Command  (NORAD) ,  a 
bi-national  United  States  and  Canadian  command,  is  responsible 
for  detecting  an  air  or  missile  attack  on  North  America,  assess¬ 
ing  the  nature  of  the  attack,  and  notifying  United  States  and 
Canadian  leaders  of  the  attack.  This  mission  is  accomplished 
through  a  system  of  space  and  air  surveillance  sensors,  communi¬ 
cation  devices,  and  computers  which  pass  data  to  information 
processing  centers  at  Cheyenne  Mountain  Air  Force  Base  near 
Colorado  Springs,  Colorado.  These  centers  pass  the  processed 
surveillance  information  to  the  NORAD  Command  Post  (NCP) ,  also 
located  within  Cheyenne  Mountain.  The  duty  of  the  Command  Post 
is  to  assess  the  information  it  has  received  and  to  complete  the 
proper  notification  in  a  timely  manner.  The  successful 
functioning  of  this  warning  system  is  a  pillar  of  deterrence. 

The  command  centers  in  Cheyenne  Mountain  are  operated  by 
the  United  States  Space  Command  (USSPACECDM) ,  a  unified  command 
made  up  of  the  Air  Force  Space  Command  (AFSPACECOM) ,  the  Army 
Space  Command,  and  the  Naval  Space  Command.  Located  at  Peterson 
Air  Force  Base  near  Colorado  Springs,  USSPACECOM  is  responsible 
for  ensuring  that  NORAD  is  supported  with  the  computer  systems 
it  needs  to  perform  its  critical  warning  and  assessment  mission. 
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AFSPACECOM  implements  the  support,  and  the  Electronic  Systems 
Division  (ESD)  of  the  Air  Force  Systems  Command  (AFSC)  serves  as 
acquisition  agent. 

Historically,  NORAD  computer  acquisitions  have  been 
characterized  by  changing  requirements,  schedule  delays,  and 
budget  overruns.  These  have  led  to  repeated  investigations  by 
Congress,  by  the  United  States  General  Accounting  Office,  and  by 
Department  of  Defense  agencies.  This  paper  discusses  the 
history  of  these  acquisitions  in  order  to  understand  the  factors 
which  have  contributed  to  these  problems  and  to  determine 
principles  which,  if  implemented,  may  improve  the  acquisition 
process. 


Problem  Statement 

What  factors  historically  have  contributed  to 
problems  with  Cheyenne  Mountain  system  acquisitions? 

What  principles  historically  have  been  successful 
and  may  contribute  to  future  successful 
acquisitions? 


Assumptions 

Recently,  investigators  have  attempted  to  measure  the 
success  of  programs  by  cost  effectiveness,  i.e.,  fielding  a 
system  as  capable  as  possible,  as  close  to  schedule  as  possible, 
and  for  the  appropriate  cost.  (1:2S>  These  criteria  are  used  in 
this  paper  to  measure  the  success  of  a  program  from  the  manage¬ 
ment  point  of  view.  The  operational  measure  of  a  successful 


2 


program  is,  however,  subjective.  It  the  system  does  not  meet 
the  user's  basic  needs,  then  meeting  the  job  specification  on 
time  and  within  budget  does  not  matter.  The  user  must  be 
satisfied. 


Limitations 

The  author's  years  of  involvement  with  the  Cheyenne 
Mountain  computer  systems  provide  a  unique,  personal  point  of 
view  for  this  study.  Many  statements  are  based  upon  personal 
observation  and  are  difficult  to  verify  independently.  Also, 
the  author's  involvement  with  a  relatively  successful  phase  of 
the  upgrade  program  introduces  some  bias.  Similarly,  hindsight 
bias  can  perturb  analysis  in  a  field  of  rapidly  changing 
technology  such  as  computer  science.  (2:22)  It  is  hoped  that 
careful  analysis  will  minimize  these  potential  problems. 

Organizations  and  relationships  in  these  acquisitions 
are  extremely  complex.  To  some  extent,  they  have  been 
simplified  to  make  the  subject  comprehensible  by  the  general 
reader. 

There  are  limits  to  what  can  be  done  in  a  short  time  by 
a  single  researcher.  There  is  a  wealth  of  writings  on  program 
management,  software  development,  and  leadership.  Even  after 
the  effort  spent  by  this  researcher,  some  excellent  advice 
pertinent  to  environments  like  Cheyenne  Mountain  may  have  been 


missed. 


Background  In-format  ion 


Command  and  control  systems  have  several  features  which 
distinguish  them  from  other  systems.  These  systems  are  software 
dominated  and  are  generally  implemented  on  commercial  off-the- 
shelf  hardware.  (3:20)  They  are  one-of-a-kind  systems  with  the 
development  model  being  the  final  operational  product.  (3:19) 
They  are  information  systems  which  must  perform  acceptably  with 
imperfect  information  and  which  must  degrade  gracefully  under 
stress.  (4:5)  They  greatly  reflect  the  personality  of  the 
commander  using  them  and  therefore  require  flexibility.  (4:5) 
Success  of  command  and  control  systems  is  difficult  to  define 
because  performance  measures  for  these  systems  are  ultimately 
subjective.  (3:19)  Finally,  these  systems  are  typically 
embedded  within  a  larger  framework  of  interconnected  systems. 

(3: 19) 

Complex  systems  historically  have  been  implemented  by 
either  a  conventional  or  an  evolutionary  acquisition  strategy. 
The  conventional  strategy  is  designed  for  systems  with  well- 
understood  requirements  needing  little  refinement  during 
development.  "A  conventional  acquisition  strategy  requires  a 
detailed  definition  of  the  capabilities  and  characteristics  of 
the  entire  system  before  starting  full-scale  development.’1  (4:6) 
This  strategy  produces  turnkey  systems,  which  are  intended  to  be 
finished  products.  Conventional  strategies  have  traditionally 
been  overseen  contractual 1 y  by  the  military,  but  have  been 
managed  by  civilian  agencies  who  are  contracted  to  deliver  the 
specified  product.  With  civilian  contractor  management,  changes 
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in  the  program  require  renegotiation  of  the  contract. 

The  evolutionary  strategy  is  designed  for  systems  which 
will  change,  or  evolve,  during  development  but  which  remain 
within  a  defined  archi tectural  framework.  (4s 3)  An  evolutionary 
strategy  addresses 

...  the  need  to  field  a  well-defined  core 
capability  quickly  in  response  to  a  validated 
requirement,  while  planning  through  an 
incremental  upgrade  program  to  eventually 
enhance  the  system  to  provide  the  overall 
system  capability.  ( 4  s  3 ) 

With  evolutionary  acquisitions,  management  by  the  military  is 
possible  with  contractors  responsible  for  specific  tasks  within 
the  greater  acquisition. 

For  NORAD  systems,  when  Air  Force  Systems  Command  (AFSC) 
is  the  acquirer,  a  System  Program  Office  (SPO)  is  assembled  with 
the  SPO  director  as  the  single  agent  responsible  for 
acquisition.  <5:S>  When  Air  Force  Space  Command  (AFSPACECOM)  is 
involved  with  an  acquisition,  a  Command  Manager  (CM)  represents 
AFSPACECOM  on  all  matters  relating  to  the  acquisition.  (5:9-10) 

Contents 

This  examination  begins  in  Chapter  II  with  a  history  of 
the  original  NORAD  Combat  Operations  System  (NOCOPS,  or  425L) 
and  the  original  space  defense  computational  system  (496L) . 
Chapter  III  treats  the  Cheyenne  Mountain  Improvement  Program 
(427M)  which  replaced  the  original  programs.  Chapter  IV  begins 
with  the  Cheyenne  Mountain  Upgrades  which  are  designed  to 
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replace  427M  and  concludes  with  the  -formulation  o-f  the  Granite 
Sentry  agreement.  Chapter  V  presents  the  principles 
incorporated  into  the  plan  for  the  Granite  Sentry  acquisition. 
Chapter  VI  covers  the  implementation  through  1989  of  Phases  I 
and  II  of  Granite  Sentry.  Each  of  the  foregoing  chapters 
attempts  to  elucidate  the  factors  which  have  complicated  and  the 
principles  which  have  facilitated  the  acquisition  process  at 
each  stage.  Chapter  VII  summarizes  the  principles  learned  from 
this  historical  analysis  and  which,  if  implemented,  may  help  to 
structure  a  better  Cheyenne  Mountain  acquisition  model. 
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CHAPTER  II 


THE  ORIGINAL  SYSTEMS 

There  are  three  historical  stages  of  the  Cheyenne  Moun¬ 
tain  information  system.  The  first  stage  was  the  425L  NORAD 
Combat  Operations  System  (NOCOPS)  and  the  associated  496L  space 
defense  computational  system.  These,  and  other  related  systems, 
were  hosted  on  multiple  processing  units.  The  second  was  the 
Cheyenne  Mountain  Improvement  Program  (427M) ,  a  relatively  mono¬ 
lithic  system  which  replaced  the  first  system  in  1979.  The 
Cheyenne  Mountain  Upgrades,  which  includes  Granite  Sentry,  is 
the  third  stage  which  is  currently  replacing  427M  by  a 
distributed  architecture  system.  This  chapter  discusses  the 
development  of  the  original  425L.  and  496L  systems. 

In  1959,  the  Air  Force  began  to  construct  a  survivable 
Combat  Operations  Center  (COO  to  house  the  operational  NORAD 
centers.  (6:2)  (7:1)  These  included  the  NORAD  Command  Post,  the 

Battle  Staff  Support  Center,  the  Weather  Support  Unit,  and  the 
Air  Defense  Operations  Center  (ADOC) .  An  information  processing 
system,  designated  425L,  would  be  developed  to  support  the  COC. 
All  of  the  centers  would  have  appropriate  communications  links 
as  well  as  closed-circuit  television  displays.  (7:28) 

Through  1959,  the  Air  Force  mission  of  the  COC  was  to 
counter  a  manned  bomber  threat.  However,  with  the  increasing 
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missile  threat  at  the  turn  of  the  decade,  Headquarters  USAF  re¬ 
directed  planning  to  stress  missile  attack  warning  and  space 
computation.  (6:2)  The  Air  Force  planners  were  thrust  from  a 
comfortable,  wel 1 -understood  bomber  defense  to  one  involving 
concepts  and  software  which  had  not  yet  been  developed. 

Recognizing  the  problems  inherent  in  developing  complex 
systems,  the  Department  of  Defense  commissioned  the  1960  Winter 
Study  Panel  to  overview  the  issue.  The  panel  expressed  concern 
over  the  difficulties  of  integrating  systems  m  the  absence  of  a 
consistent  set  of  operational  objectives  and  standards  for 
system  design.  (8:2)  It  recommended  an  evolutionary  acquisition 
approach  for  one-of-a-kind  systems.  (8:1)  Following  the  Winter 
Study  recommendations,  requirements  dated  19  June  1961  directed 
that  425L  be  acquired  in  a  five-phase  evolutionary  manner,  that 
an  experimental  test  facility  be  constructed,  and  that  the  pro¬ 
gram  be  managed  by  the  military.  (6:3)  The  program  would 
utilize  commercial  off-the-shelf  equipment  from  industry  or  from 
government  sources.  (6:3)  (7:27)  Two  not-for — profit 

corporations,  the  MITRE  Corporation  and  System  Development 
Corporation,  were  designated  as  system  designer  and  software 
developer,  respectively.  The  Electronic  Systems  Division  (ESD) 
of  Air  Force  Systems  Command  (AFSC)  would  serve  as  acquisition 
agent  for  the  project. 

For  the  next  four  years  425L  was  evolved  through  four 
pre-operational  phases.  Several  other  programs  under 
simultaneous  development  by  other  governmental  agencies  were 
required  to  be  included  in  the  CDC  and  to  be  integrated  with  the 
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425L  system.  <6: 3)  These  programs  were  the  Defense 
Communications  Agency  communications  processors,  the 
Intelligence  Data  Handling  System  (IDHS),  the  Ballistic  Missile 
Early  Warning  System  (BMEWS)  Display  Information  Processor 
(DIP),  a  display  distribution  system,  and  the  closed  circuit 
television  system.  (40s 6)  As  a  result  of  the  diverse  programs, 
independent  organisations,  and  interfaces,  the  equipment 
configuration  changed  many  times.  (7:36)  Other  changes 
concerned  how  the  space  tracking  system,  496L.,  would  interface 
with  the  425L  system.  The  agencies  involved  with  NORAD  could 
not  agree  on  the  integration  requirements  or  a  baseline, 
resulting  in  halting  progress,  program  slips,  and  increased 
cost.  (7:36) 

Progress  on  Cheyenne  Mountain  integration  languished. 

On  29  October  1963,  the  US  Department  of  Defense  Office  of 
Development,  Research  and  Engineering  brought  its  concern  over 
the  changing  requirements,  increasing  costs,  slipping  schedules, 
and  integration  problems  to  the  attention  of  the  Secretary  of 
Defense.  (7:27)  In  December,  the  Secretary  directed  CINC  NORAD 
to  appoint  the  Cheyenne  Mountain  Complex  Task  Force  to  study  in 
depth  the  "requirements,  technical  design,  operational  plan,  and 
acquisition  management  for  the  NORAD  COC  complex  of  systems  in 
Cheyenne  Mountain."  (42:44)  The  term  "Cheyenne  Mountain 
Complex"  (CMC)  was  formalised  to  mean  all  of  the  computer 
systems  within  the  mountain.  (7:27)  The  task  force  recommended 
that  a  single  agency  be  appointed  responsible  for  Cheyenne 
Mountain  integration.  (41:74) 
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As  a  result,  the  Secretary  of  Defense  directed  the  form¬ 


4? 


ation  of  the  Cheyenne  Mountain  Complex  Management  Office 
(CMCMO),  a  single  manager  responsible  for  bringing  the  COC  to 
initial  operational  capability  (IDG).  The  CMCMO  was  headed  toy 
an  ESD  officer  with  a  NORAD  deputy.  (41:74;  The  ESD  Program 
Director  reported  to  the  ESD  Vice  Commander.  (9:44)  The  NORAD 
Deputy  personally  represented  CINC  NDRAD.  (7:39)  With  the 
exception  of  the  contracting  officer,  the  entire  team  was 
located  in  Colorado  Springs.  Other  implemented  recommendations 
were  a  finalised,  baseline  equipment  configuration,  the 
separation  of  missile  warning  from  space  defense,  and  the 
continuation  of  the  experimental  test  facility.  (7:40) 

With  the  formation  of  the  CMCMO  in  July  1964,  the  in¬ 
dividual  programs  bsgan  to  see  real  progress.  Within  18  months, 
the  425L  system  reached  IOC.  (6:4)  In  all,  eleven  other  systems 
were  integrated  with  425L  over  the  next  four  years,  including  an 
early  version  of  the  Command  Center  Processing  and  Display 
System  (CCPDS)  which  was  necessary  to  provide  a  catastrophic 
failure  backup  for  425L  and  the  DIP.  It  also  gave  CINC  NORAD 
the  same  display  of  the  same  information  seen  in  the  Strategic 
Air  Command  (SAC)  comm-V1.:  post.  Interface  to  496L,  however, 
remained  manual , 

In  its  Cheyenne  Mountain  Complex  Final  Technical  Review 
(CMCFTR)  of  May  1966,  the  CMCMO  summarized  the  key  points  which 
finally  led  425L  and  496L  to  successful  completion,  and  it  re¬ 
commended  that  they  be  used  in  similar  programs  in  Lhe  future. 
System  flexibility  was  essential  because  of  constant  change  in 
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the  world  environment  and  because  of  changes  in  the  inter-faces 
dictated  by  changing  system  users.  (6:26)  The  evol utionarv 
growth  concept  “J^s  a  major  contributor  to  success.  There  must 
be  su-f-ficient  a  -  between  stages  to  allow  lessons  learned  in 
one  stage  tl-  b-"1  i  porated  in  the  next.  (6:28)  Qperati  on'al 
test-beds  and  a  :ock-up  o-f  the  command  post  should  be  located 
close  to  the  usv  .  but  remain  under  the  developer's  control  to 
prevent  the  use.  . .  am  using  the  tesc-bed  operationally  and 
interfering  with  testing.  (6:26)  The  design,  hardware,  and 
contractor  management  should  be  be  controlled  by  the  military 
rather  than  by  contractors.  This  approach  was  perceived  to  give 
maximum  effect  for  minimum  dollars  expended.  (6:28)  Finally,  a 
sizeable  detachment  of  the  program  office  should  be  col  located 
with  the  user.  Collocation  reduced  response  time  and 
facilitated  turning  the  system  over  on  schedule.  (6:285 

In  summary  the  system  was  a  one-of-a-kind  product  which 
pushed  the  state  of  the  art  of  computer  science.  Performance 
requirements  were  changing  during  implementation,  and  interfaces 
were  challenging  due  to  the  use  of  multiple  hardware  types. 
Management  was  fragmented  with  unclear  channels  of 
responsibility  and  authority  to  see  that  the  program  was 
executed.  The  Secretary  of  Defense  directed  formation  of  a 
single  management  organisation  which  brought  the  SPO  to  the  user 
and  the  original  systems  to  operational  status. 


11 


CHAPTER  III 


THE  CHEYENNE  MOUNTAIN  IMPROVEMENT  PRODRAM 

As  '.he  425L  and  496L  systems  reached  IOC  in  1966,  there 
were  f.ojections  of  growing  Soviet  ballistic  missile 
capabilities  and  a  steady  incr  'ase  in  the  number  o-f  earth 
orbiting  objects.  Within  a  decade,  <he  existing  systems  would 
be  inadequate  -for  NORAD's  mission  requirements.  (10:7)  Further, 
the  equipment  w;..s  first  generation,  transistor  vintage.  As  it 
aged,  there  would  be  growing  problems  with  reliability  and  parts 
.availability.  Finally,  Cheyenne  Mountain  had  no  uninterrupted 
power  supply;  power  fluctuations  within  the  CMC  had  damaged 
system  ardware,  sometimes  with  loss  or  alteration  of  data. 

(10:7)  Consequently,  in  June  .1969,  NC»  "D  began  formal  planning 
of  the  Cheyenne  Mountain  Improvement  Program  427M,  a  replacement 
for  425L,  496L,  the  Display  Information  Processor ,  ,  rd  their 
communications  systems.  This  replacement  was  though,  to  entail 
a  simple  rehasting  of  existing  software  to  more  capable 
computers.  (1.1:25)  After  the  rehosting  reached  IOC,  the  program 
would  evolve  whatever  additional  capabilities  were  needed. 
Unfortunately,  the  contracting  structure  did  not  support  the 
evolutionary  phase  of  the  effort.  (12:85) 

In  order  to  address  the  previous  problem  of  multiple 
interfaces,  427M  was  designed  to  be  more  monolithic  than  the 
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distributed  systems  it  replaced.  The  number  of  mainframe 
computers  would  drop  from  11  to  two.  These  two  machines  would 
perform  all  of  the  space,  air,  missile  warning,  and  command  and 
control  functions.  (11:25)  This  approach  appeared  valid  since 
the  computer  systems  of  the  era  far  exceeded  the  memory  and 
processing  capabilities  of  the  original  systems.  Using  only  two 
mission  machines  would  also  minimise  cost.  The  Department  of 
Defense  specified  that  the  computers  be  Honeywell  mainframes,  a 
business-oriented  system  used  in  the  World  Wide  Military  Command 
and  Control  System  (WWMCCS) .  (11:38) 

One;,  again,  as  with  the  425L  acquisition,  the  427M 
System  Program  Office  (SPO)  office  was  established  at  ESD  in 
Massachusetts  rather  than  in  Colorado  Springs.  (11:45)  In 
October  1969,  citing  the  success  of  the  CMCMO,  NORAD  requested  a 
permanent  ESD  presence  in  Colorado  Springs.  (11:45) 

Consequently,  AFSC  and  ESD  renamed  the  425L/496L  Field  Office  as 
the  427M  Field  Office,  but  did  not  give  it  any  decision-making 
capability  or  local  engineering  support.  (11:45)  The  SPO 
remained  in  Massachusetts, 

In  1971,  MITRE,  ESD,  and  NORAD  jointly  published  the 
technical  requirements  which  defined  the  specifications  for 
contractors  bidding  on  427M  contracts.  The  program  was  par — 
titioned  into  three  segments,  all  of  which  would  be  de¬ 

veloped  simultaneously.  The  NORAD  Computer  System  (NCS)  wi,..*d 
replace  the  425L  system,  the  DIP,  and  the  CCPDS,  consolidating 
missile  warning  functions  into  one  system.  (10:9)  The  Space 
Computational  Center  (SCO  would  replace  the  496L  system.  The 
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communications  processors  and  technical  control  would  be 
replaced  by  the  Communications  System  Segment  (CSS).  Each  of 
these  systems  would  be  connected  to  display  consoles  via  a 
modular  display  system,  and  the  existing  closed-circui t 
television  and  large  group  displays  would  be  inter-faced  to  the 
427M  system. 

Software  contracting  for  427M  was  cumbersome.  (11:34) 

In  October  1972,  the  Philco-Ford  Corporation  was  awarded  an 
overall  427M  integration  and  communications  contract.  System 
Development  Corporation  won  the  SCC  contract  in  early  1973. 
System  Development  was  also  responsible  for  the  hardware  for  the 
display  system  which  Ford  would  have  to  integrate.  (13:1328) 
NORAD  would  provide  the  software  for  the  NCS. 

Within  a  few  months,  Ford  had  subcontracted  to  System 
Development  for  software  work,  and  System  Development  had  sub¬ 
contracted  to  Ford  for  software  work!  (10:33)  Contract  admini¬ 
strators  were  fearful  that  efforts  would  be  confused,  and  the 
Defense  Contract  Audit  Agency  saw  the  reciprocal  arrangements  as 
an  opportunity  for  overcharging ,  fraud,  and  finger — pointing  when 
the  schedule  slipped.  (10:36)  However,  the  arrangements  had  to 
continue  lest  the  program  lose  time  during  recompetition. 

In  1974,  ESD  predicted  a  program  slip  and  cost  growth. 
AFSC  determined  that  a  third  mission-processing  node  would  be 
required  to  meet  the  processing  and  availability  requirements. 

It  also  recommended  improvements  in  the  contractor — to-SPO  com¬ 
munications  and  that  NORAD  assume  more  of  the  software  develop¬ 
ment  tasks.  Funding  was  increased,  the  schedule  was  slipped, 
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and  the  third  node  was  added.  However,  the  recommendations  for 
software  development  and  improved  communications  were  not 
followed.  (11:25) 

In  1975,  the  program  office  announced  a  further  slip. 
NORAD  again  insisted  that  the  SF'O  be  located  at  Colorado  Springs 
and  that  it  be  given  decision-authority.  NORAD  also  insisted  on 
close  coordination  with  ESD  and  close,  consistent  direction  of 
the  contractors.  (11:55)  AFSC  agreed  to  move  427M  program  man¬ 
agement  to  Colorado  Springs,  but  kept  its  business  management  in 
Massachusetts.  AFSC  would  retain  overall  project  authority,  and 
NORAD  would  perform  more  programming  in-house.  (11; 55) 

The  requirements  of  the  program  were  prioritized  so  that 
the  software  teams  could  concentrate  on  the  essential.  NORAD 
assumed  responsibility  for  the  NCS  software  integration,  for  SCC 
software,  and  for  CSS  expansion  software.  It  increased  its  role 
in  testing  427M,  it  deleted  a  major  requirements  package  in  a 
common  display  set  which  was  to  reside  on  the  SCC,  and  it  agreed 
to  an  earlier  implementation.  (11:55)  Finally,  the  SCC  contract 
was  restructured  according  to  NORAD  direction.  (11:56)  In 
short,  427M  was  modified  to  be  a  design-to-budget  effort. 

(11:55)  The  baseline,  however,  was  not  yet  frozen.  (11:56) 

Work  progressed  on  the  individual  pieces  of  427M.  Even 
though  the  WWMCCS  equipment  was  ill-suited  for  the  job,  it  was 
beginning  to  function,  although  not  to  performance 
specification.  In  1976,  NORAD  raised  427M  to  first  priority 
status,  (11:61)  and  all  NORAD  program  management  was 
concentrated  under  a  single  manager  as  Assistant  to  Vice  CINC 
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ADCOM  (the  USAF  component  of  NORAD)  for  427M.  (14:65)  In  April 
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1976  NORAD  assumed  responsibility  for  system  engineering, 
integration,  and  test  for  the  entire  427M  system.  (11:62)  MITRE 
performed  as  system  engineer  for  NORAD  and  provided  engineering 
support  to  ESD.  ESD  maintained  responsibility  for  the  CSS 
program.  (10:33) 

In  1977,  the  program  failed  a  major  milestone  when  the 
CSS  was  not  ready  for  testing  as  a  complete  system.  As  a 
result,  NORAD  requested  an  Independent  Review  Sroup  (IR6)  to 
assess  the  program.  The  IRG  noted  that  management  had  been 
fragmented —  there  was  no  single  point  of  contact  for  the 
program.  Guidance  to  software  developers  came  from  several 
NORAD  organisations,  and  differing  direction  arrived  from  ESD. 
(11:64)  (13:1328)  The  IRS  concluded  that 

joint  management  of  427M  [had]  hampered  the 
program's  progress.  ESD's  integration  role  was 
very  narrow  and  inadequate  from  a  systems 
viewpoint.  [NORAD]  was  without  a  systems 
engineering  resource  ...  The  divergent  interests 
and  the  difficulties  encountered  [indicated]  that 
total  management  responsibility  should  be  vested 
in  a  single  authority.  (10:32) 

Finally,  recognizing  the  difficulty  of  meeting  the  over — 
stated  specification  and  matching  the  performance  of  the 
original  systems,  the  IRS  concluded  that  427M  should  be  declared 
operational  when  it  reached  an  equivalent  functionality  with  the 
old  system.  This  state  was  referred  to  as  "equivalent 
operational  capability"  (EOC).  (11:38)  Following  the  IRG's 
recommendations,  CINC  NORAD  agreed  to  take  operational  control 
of  427M  and  bring  it  to  EOC  with  continued  MITRE  engineering  and 
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ESD  contract  support.  (11:65) 

CCPDS  was  originally  intended  to  be  replaced  as  part  of 
427M.  However,  427M  did  not  meet  the  availability  of  the  old 
systems,  and  the  need  for  a  more  available  missile  warning  func¬ 
tion  was  apparent.  Two  programs  were  produced  to  ensure  near 
continuous  missile  warning  availability.  The  first  was  the 
Mission  Essential  Backup  (MEBU)  software  which  was  hosted  on  the 
CCPDS  computers.  (11:57)  The  second  was  the  Missile  Warning 
Bypass  (MWBP) ,  a  communications  system  which  bypassed  CSS. 

While  there  were  reasons  for  building  these  systems,  no  criteria 
were  given  for  an  availability  of  427M  which  would  allow  their 
elimination. 

The  427M  system  requirements  were  an  excellent  example 
of  the  "second  system  effect".  (15:55)  The  first  system  built 
to  perform  a  task  is  usually  constructed  carefully  and  with  re¬ 
straint.  The  second,  or  replacement,  system,  however  is  usually 
overdesigned.  All  the  frills  and  ideas  which  were  set  aside  on 
the  first  system  tend  to  be  included  in  the  second  system. 

(15:55)  These  additions,  plus  the  natural  tendency  to  produce  a 
perfect  system,  can  lead  to  impossible  requirements.  The 
original  427M  specifications  simply  were  not  attainable  with  the 
technology  of  the  times.  (13:1327)  Compounding  the  problem, 
continued  software  baseline  changes  had  improved  425L  and  496L 
so  much  that  by  1977,  when  427M  arrived  at  1974-level 
performance,  the  new  system  was  three  years  of  changes  behind. 
(11:23)  The  defining  of  "Equivalent  Operational  Capability"  by 
the  IR6  was  an  acknowledgment  that  427M  was  far  short  of  the 
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requirements. 

In  summary,  limitations  of  a  business  computer  system,  a 
limited  commercial  operating  system  which  had  to  be  enhanced  in 
mid-stream,  and  the  addition  of  non-WWMCCS  interface  computers 
were  significant  obstacles.  The  NORAD  programming  agency  con¬ 
tinued  to  release  versions  until  1977.  Contractors  proceeded 
with  the  bidding,  hoping  that  engineering  change  proposals  (ECP) 
would  correct  financial  as  well  as  schedule  problems.  (13:1327) 
But  the  entire  original  CMC  system  could  not  simply  be  rehosted 
to  a  modern  computer  system,  and  the  requirement  to  automate  the 
original  space  manual  operator  functions  and  display  functions 
was  beyond  the  scope  of  1970 's  technology.  (10:215)  The  assump¬ 
tion  was  erroneous  that  a  modern,  time-sharing  system  could 
exceed  the  capabilities  of  the  11  distributed  systems  of  the 
vintage  mountain.  Specifications  were  not  adjusted  to  the  real¬ 
ity  of  the  hardware  and  software  system  until  near  the  end  of 
the  program.  However,  in  three  extra  years,  with  twice  the 
originally  budgeted  funds,  and  under  the  criticism  given  by 
numerous  monitoring  agencies,  427M  eventually  reached  the  first 
stage  of  its  evolution,  EOC,  in  September  1979. 

Thus,  the  427M  acquisition  suffered  from  many  of  the 
same  problems  as  the  original  system.  There  was  no  single 
authority  to  ensure  execution  of  the  over — ambitious, 
one-of-a-kind  project  with  rapidly  changing  requirements  whose 
management  was  located  remote  from  the  user.  NDRAD  involvement 
escalated  until  it  was  responsible  for  integration  and  all  of 
the  software  except  communications.  Bringing  427M  to  EOC 
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reqi  red  user  involvement  in  a  single  integration  organisation, 
mov;  g  a  portion  of  the  SPQ  to  Colorado  Springs,  and  military 
management  of  the  contractor  resource  by  both  ESD  and  NORAD.  No 
real  progress  was  made  until  the  user  component  was  moved  under 
the  Vice  Commander. 
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CHAPTER  IV 


THE  CHEYENNE  MOUNTAIN  UPGRADE  PROGRAMS 

On  9  November  1979  and  again  on  3  and  6  June  1900,  the 
427M  system  transmitted  missile  attack  indication  messages  to 
SAC  and  to  the  National  Military  Command  Center  in  Washington. 
Consequently,  427M  became  the  subject  of  a  series  of 
investigations  which  concluded  that  the  fragmented  management  of 
its  acquisition  was  a  prime  reason  for  its  problems.  (16:13)  In 
the  paper,  NORAD  Computer  Systems  are  Dangerously  Obsolete,  the 
House  of  Representatives  confirmed  that  427M  needed  to  be 
replaced.  (17:17)  The  replacement  programs  for  the  427M  system 
were  designated  the  Cheyenne  Mountain  Upgrades  (CMU) .  (10:1) 

The  upgrades • were  to  implement  a  distributed  architec¬ 
ture  tied  together  by  a  robust  Communications  System  Segment 
Repl acement.  (CSSR)  .  The  CSSR  would  handle  all  CMC  internal  and 
external  data  communications  with  the  exception  of  certain 
intelligence  information.  (19:13)  Missile  warning  functions  on 
the  NORAD  Computer  System  (NCS) ,  the  Mission  Essential  Backup 
(MEBU) ,  and  the  Command  Center  Processing  and  Display  System 
(CCPDS)  would  be  replaced  by  the  Command  Center  Processing  and 
Display  System  Replacement  (CCPDSR) .  Space  surveillance 
functions  would  be  replaced  by  the  Space  Defense  Operations 
Center  (SPADOC) .  The  formal  program  start  was  early  19B1 ,  with 
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a  scheduled  completion  of  March  1987.  (17518)  The  remainder  of 

the  NOS  functions  of  Battle  Staff  Support,  Weather,  Air  Defense, 
the  NORAD  Command  Post,  and  the  production  of  integrated 
displays  were  to  be  consolidated  into  the  NCS  Replacement 
(NCSR) .  (1854)  A  conventional  strategy  was  selected  for  the 

CSSR,  SPADOC,  and  CCPDSR  acquisitions.  Each  of  the  System 
Program  Offices  was  located  in  Massachusetts.  The  acquisitions 
were  to  be  turnkey,  but  were  to  be  acquired  in  increments. 
Specifications  were  written,  competitions  run,  and  contracts 
awarded. 

Immediately,  CSSR  began  to  experience  growth  in  require¬ 
ments  and  cost.  By  19S9,  the  cost  of  the  program  had  risen  from 
$202  million  to  $350  million.  The  IOC  for  Block  I  slipped  to 
1990.  Block  II  was  awarded  in  February,  1987,  with  IOC 
scheduled  for  1991.  (19s27)  Thus,  conceived  in  1981,  CSSR  will 

take  as  long  to  develop  as  the  entire  427M  system.  SPADOC  was 
conceived  as  a  rehosting  followed  b/  a  four-phase  evolution.  By 
1989,  SPADOC  had  increased  in  price  from  $290  million  to  $487 
million,  and  the  IOC  had  slipped  from  1988  until  1994.  SPADOC 
will  take  almost  a  decade  to  complete.  (20548)  In  1987,  the 
CCPDSR  operational  date  was  slipped  until  1992  in  order  to 
accommodate  the  rising  program  costs  of  SPADOC  and  CSSR  and  to 
avoid  the  turmoil  of  having  too  many  programs  in  simultaneous 
test  within  the  CMC. 

As  a  result  of  the  development  problems,  the  US  General 
Accounting  Office  (GAO)  investigated  CMU  in  depth.  The  GAO  con¬ 
cluded  that  the  use  of  commercial  off-the-shelf  operating 
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systems  for  CSSR  caused  an  unacceptably  slow  restart  from  a 
power  outage.  Further,  CSSR  could  not  meet  the  required  message 
throughput,  and  wiring  and  message  standards  were  lacking  for 
communication  among  programs.  (19:4-6)  GAO  further  observed 
that  technical  control  was  at  its  growth  limit,  and  that  the 
users  and  acquirers  did  not  agree  on  the  specifications  of  the 
system.  (19:21)  The  GAO  noted  computer  security  problems  in 
SPADOC  Block  4.  (20:48)  After  seven  years  of  development,  the 

system  did  not  meet  14  of  23  performance  requirements.  (20:13) 
The  entire  CMU  was  criticised  as  having  no  single  organisation 
truly  in  charge.  (17:23)  The  report  ackowledged  that  the 
problem  resolution  structure  documented,  formally  tracked,  and 
discussed  problems,  but  emphasized  that  it  did  not  often  resolve 
them.  (17:23) 

The  lists  of  problems  constituted  a  repeat  of  the  427M 
difficulties  couched  in  the  computer  specifications  of  the  80s. 
The  "second  system"  problems  of  automating  the  man-machine 
interface  and  integrating  man  missions  on  a  single  system 
unsuited  for  the  job  were  reborn.  Color  graphic  displays  were 
asked  to  switch  as  fast  as  a  monochrome  system  to  display  a 
database  one  thousand  times  as  large.  Sophisticated  custom 
computer  security  enhancements  slowed  the  basic  system  down  to 
the  point  that  almost  no  work  could  be  performed.  The  modern 
operating  system  of  perhaps  a  billion  instructions  was  expected 
to  load  as  quickly  as  its  1960s  counterpart  of  3000 

l  * 

instructions.  Pressing  the  state-of-the-art  caused  the 
contractors  repeatedly  to  redesign  and  augment  the  commercial 
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software. 


Software  maintainors  numbering  several  hundred  Air  Force 
and  contractor  personnel  were  experts  on  the  current  systems 
which  they  had  maintained  for  10  years.  The  maintenance  organ¬ 
isation  could  make  gigantic  changes  in  a  single  release. 
Improvements  in  427M  made  it  perform  almost  as  well  as,  if  not 
better  than,  the  replacement,  exaggerating  the  user's 
expectations  for  the  replacement  and  setting  the  stage  for 
disappointment.  (19:27-29)  The  specified  capabilities  for  the 
CMU  did  surpass  those  of  427M.  For  example,  the  CSSR  is 
specified  to  exceed  the  existing  CSS  in  10  critical  areas. 

(21:7)  Unfortunately,  the  CSSR  has  not  yet  been  proven,  and  it 
will  have  a  hard  test  against  the  mature  11  year — old  system. 

The  interface  among  systems  was  designated  a  potential 
problem  area  in  1982  by  a  review  committee  called  for  the 
purpose  of  exploring  the  risks  and  benefits  of  a  distributed 
processing  system.  (22:2)  Standardization  in  message  protocols 
and  formats  was  cited  as  critical  for  implementing  the 
archi tecture.  Unfortunately,  the  CSSR,  SPADOC,  and  CCPDSR 
programs  went  on  contract  with  different  message  sets  and 
protocols.  (17:24-25) 

The  most  condemning  criticism  was  that  there  was  no 
single  entity  in  charge  of  either  the  42711  development  or  of  the 
current  modernizations.  (17:3)  Numerous  agencies  were  in 
charge,  but  none  truly  responsible  for  success.  The  current, 
traditional  program  organizations  did  not  readily  share  risk  and 
success  as  did  the  final  CMCMO  and  427M  organizations.  A  19B3 
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attempt  to  reestablish  a  single  manager  -for  the  CMU  resulted  in 
the  management  being  assigned  to  the  Systems  Integration  Office. 
(23:1)  That  agency  was  responsible  for  CMU  interface  and 
certification  standards,  but  it  could  only  enforce  standards 
indirectly  by  refusing  to  certify  a  system.  (45:3)  Thus,  the 
CMU  was  experiencing  problems  similar  to  the  previous  systems. 

In  May  1983,  plans  for  the  NORAD  Computer  System  Re¬ 
placement  (NCSR)  began  to  be  coordinated  through  the  NORAD 
staff.  The  goals  for  the  NCSR  were  minimal  operational  risk,  an 
achievable  schedule,  and  interfaces  to  other  programs.  (24:1) 

The  NCSR  was  planned  to  begin  in  1986  with  IOC  in  1980.  As  with 
the  427M  acquisition,  the  schedule  was  short  because  the  task 
was  seen  by  NORAD  to  be  a  software  rehosting  effort.  (25:1)  By 
February  1984,  HQ  Air  Force  Operations  Plans  questioned  the 
optimistic  schedule.  (26:1)  By  April  1985,  ESD  provided  the 
first  cost  estimate  of  $489  million.  General  Herres,  CINC 
NORAD,  questioned  both  the  architecture  and  the  cost,  insisting 
on  "clearly  defined  program  objectives  broken  down  into 
sequential  implementation  packages.  11  (27:1) 

The  SPO  then  proposed  an  incremental  development  which 
would  begin  with  the  Air  Defense  Operations  Center  (ADOC)  in 
1986,  but  which  included  no  schedule  for  the  NORAD  Command  Post, 
the  Battle  Staff  Support  Center,  or  for  the  Weather  Support 
Unit.  Each  of  these  programs  was  to  be  a  separate,  future 
acquisition.  Questioning  the  three-year  ADOC  schedule  and  the 
number  of  acquisitions,  CINC  NORAD  directed  his  staff  to  examine 
alternative  ways  of  executing  the  NCSR.  Consequently,  the 
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remaining  -functions — Battle  Staff  Support,  ADOC,  and  Weather 
Support — were  consol i dated  into  the  Granite  Sentry  Program  in  a 
statement  of  need  written  19  July  19B5.  (28:1) 

Meetings  at  all  levels  during  the  fall  of  1986  resulted 
in  an  agreement  between  CINC  NORAD  and  the  commander  of  ESD. 
Granite  Sentry  would  be  executed  in  an  evolutionary  fashion, 
with  each  phase  building  on  the  previous  phase.  Represented  by 
ESD  and  AFSPACECOM,  the  Air  Force  would  be  the  military  manager 
for  the  project.  Both  commands  would  function  as  overall  risk- 
takers.  (29:49)  ESD  would  provide  program  support  and  manage¬ 
ment,  and  AFSPACECOM  would  develop  the  software.  (29:49)  (30:7) 

Both  commands  would  contribute  other  support  as  needed  to  ensure 
priority  execution.  (30:10)  Although  these  tasks  might  be  ac¬ 
complished  with  contract  support,  responsibility  would  clearly 
fall  on  the  appropriate  military  organisations.  (29:49)  Most 
important,  ESD  was  identified  as  the  single  agency  ultimately 
responsible  for  execution.  ESD  would  assist  in  program  advocacy 
and  would  be  the  final  arbiter  of  schedule  and  cost  discussions. 
In  a  sense,  AFSPACECOM  would  act  as  a  software  and  systems  con¬ 
tractor  to  ESD.  This  arrangement  ensured  that  one  agency  was  in 
charge  of  the  program,  but  it  incorporated  shared  risks  and 
responsibilities.  The  initial  cadre  of  AFSPACECOM  developers 
was  tasked  to  work  out  the  mechanics  of  the  program  with  the  ESD 
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CHAPTER  V 


GRANITE  SENTRY  PRINCIPLES 

From  November  19B6  until  March  1987,  the  AFSPACECOM  and 
ESD  components  of  the  newly  formed  Granite  Sentry  Cadre  met  to 
finalise  the  ground  rules  for  implementation.  ESD  would  provide 
a  program  office  in  Colorado  Springs  with  its  deputy  and  other 
personnel  collocated  with  the  AFSPACECOM  development  office. 
AFSPACECOM  would  enhance  the  initial  staff  of  eight  pi- ogrammers 
with  a  programming  ..earn  of  40  beginning  in  January  1987.  (31s  1) 

The  key  personnel  from  both  commands  were  to  be  frozen  for  four 
years,  thus  ensuring  continuity  of  management  and  a  consistent 
viewpoint.  (30:7)  The  program  would  be  executed  within  the  1987 
budget  of  $141  million  through  1991,  and  ESD  would  not  make 
funding  adjustments  without  AFSPACECOM  concurrence.  (30:15)  The 
problems  of  changing  baseline  and  interface  requirements  were 
addressed  by  limiting  427M  version  releases  to  one  per  year. 
Emergencies,  of  course,  would  be  excepted.  (30:7) 

The  program  would  be  implemented  in  five  evolutionary 
phases  with  two-year  delivery  cycles  overlapping  by  one  year. 
(29:45)  The  shortened  development  cycle  was  intended  to  control 
requirements  growth.  The  logic  was  that,  if  the  user  knew  he 
would  have  to  wait  no  more  than  24  months  and  that  the  phase 
planning  provided  for  new  requirements,  there  would  be  less 
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pressure  to  change  the  baseline  in  mid-phase. 

The  user  would  be  intimately  involved  with  the  develop¬ 
ment  •from  phase  definition  through  testing,  and  would  help  de¬ 
fine,  agree  upon,  arid  prioritize  capabilities  to  be  implemented 
in  each  phase.  If  the  schedule  ran  out  before  a  part  of  the 
software  was  finished,  the  user  would  choose  whether  to  slip  the 
schedule  or  to  postpone  some  requirements  to  a  future  phase. 

The  phasing  provided  slack  for  accommodati ng  high  priority 
requirements  slips  from  prior  phases. 

A  distributed  computer  architecture  was  adopted  to  allow 
maximum  flexibility  of  mission  and  display  processing.  The 
system  would  rely  to  the  maximum  extent  possible  on  unmodified 
commercial  off-the-shelf  software  and  hardwire  from  a  single 
vendor.  Using  a  single  vendor  was  intended  to  be  a  risk-reducer 
as  well  as  a  f orce-multipl ier.  Since  all  interfaces  except  the 
external  world  would  be  through  one  vendor's  standard  products 
and  protocols,  a  single  entity  would  be  responsible  for  correc¬ 
tin'!  system-level  integration  problems.  The  military  software 
r«  sources  would  be  concentrated  on  mission  software.  (30:6) 
Equipment  for  any  phase  would  be  the  best  production  models 
available  for  mass  purchase.  Staying  close  to  but  not  at  the 
state  of  the  art  would  bring  the  most  current  technology  to  the 
Cheyenne  Mountain  user. 

As  discussed  in  the  previous  chapter,  extremes  of 
computer  system  security  had  hurt  other  programs.  Unless  NORAD 
was  willing  to  pay  for  it  in  both  cost  and  schedule,  no 
elaborate  security  measures  would  be  implemented.  Should 
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security  implementation  be  required,  only  commercially  available 
security  packages  from  the  vendor  would  be  used,  and  these  only 
when  their  use  would  not  degrade  overall  system  performance. 

Such  a  choice  would  allow  the  vendor  to  maintain  its  security 
packages  under  normal  vendor  configuration  control.  (30:6) 

The  operational  system  would  be  tested  on  a  full -up 
system  conf iguration  test-bed  located  away  from  the  operational 
environment  but  able  to  be  connected  to  the  current  system  test¬ 
bed.  (29:19)  This  allowed  as  realistic  testing  as  possible 
short  of  the  operational  environment.  Each  phase  would  be 
prototyped  starting  with  displays,  since  a  good  display  would 
mean  more  accurate  specification,  more  on  target  coding,  and  a 
happier  user. 

Implementation  of  ADQC  within  24  months  was  selected  as 
the  Phase  I  challenge.  (29:5)  The  baseline  system  needed  to  be 
expandable  to  accommodate  subsequent  phases;  it  was  partitioned 
into  communications  processing,  mission  processing,  and  display 
processing.  The  existing  Communications  System  Segment  (CSS) 
was  to  be  used  for  connection  to  the  external  air  surveillance 
and  control  systems.  Phase  I  (ADOC)  would  be  connected  in 
parallel  with  the  427M  system,  allowing  the  operators  a  choice 
of  which  system  to  use  for  air  defense.  Vendor  communications 
buses  would  interconnect  the  Phase  I  computers  and  provide  for 
the  required  flexibility  and  growth. 

In  order  to  move  into  a  renovated  NORAD  Command  Post  by 
1990,  the  remaining  command  post  functions  of  missile  warning 
and  space  display  needed  to  be  accomplished  on  Granite  Sentry 
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equipment.  (29:5)  Missile  warning  was  chosen  as  the  Phase  II 
implementation  since  it  was  the  most  time-criti cal  function. 

The  1990,  Phase  III  delivery  would  consist  of  the  renovated 
command  post  and  the  space  display  software.  In  1991,  the  CSSR 
and  SPADOC  systems  would  be  delivered  in  Phase  IV.  Effort  that 
year  would  be  reserved  for  interfacing  these  systems  and  for  any 
required  clean-up  work  from  the  previous  phases.  In  1992  and 
1993,  the  Phase  V  task  would  be  display  and  interface  processing 
related  to  WWMCCS  Information  System  and  the  Advanced  Weather 
Display  System.  Additionally,  the  space  processing  functions 
would  be  transferred  to  SPADOC  as  the  final  phase  of  SPADOC  was 
delivered.  The  overall  3cope  of  Granite  Sentry  was  ambitious. 
Each  year  would  see  at  least  one  software  release,  and  each 
program  would  require  interface  to  a  data  source  outside  the 
Granite  Sentry  system. 

The  planning  team  attempted  to  counter  potential 
problems  in  two  ways.  First,  the  effort  was  kept  as  modular  as 
possible  after  1990  in  order  to  facilitate  the  movement  of  major 
programs  should  one  of  the  interfaces  announce  a  slip.  Second, 
the  workload  in  these  years  was  light  enough  to  allow  time  for 
true  deficiencies  to  be  completely  reworked.  The  plan  was 
approved  by  both  AFSPACECOM  and  ESD  senior  staff  on  10  November 
1986,  and  the  program  moved  into  the  execution  phase  the  next 
spring. 

In  summary,  the  Cheyenne  Mountain  Upgrades  experienced 
the  same  problems  as  their  predecessors.  Born  out  of 
frustration  on  all  sides,  Granite  Sentry  in  effect  became  an 
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experiment  to  validate  the  concept  of  an  ESD  and  AFSPACECOM  team 
as  a  military  management  organisation  employing  the  principles 
o-f  collocation  o-f  major  SPO  -functions  with  the  software 
developer  and  user,  of  intense  user  involvement,  and  of  the 
evolutionary  acquisition  strategy  within  the  CMC. 
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CHAPTER  VI 


GRANITE  SENTRY  IMPLEMENTATION 

PHASES  I  AND  II 

Although  ths  senior  staff  had  agreed  to  the  shared  de¬ 
velopment  program,  there  was  much  discussion  about 
responsibility  among  the  staff  during  the  first  six  months  after 
the  reorganization  of  Granite  Sentry.  Some  organizations  felt 
that  the  SPO  should  perform  all  work  necessary  to  execute 
Granite  Sentry,  leaving  AFSPACECOM  merely  to  monitor  and  assume 
the  role  of  critic.  Others  recommended  that  AFSPACECOM  perform 
the  work  itself  reducing  ESD  to  a  monitoring  role.  The  program 
office  believed  that  such  unbalanced  division  would  be 
counterproducti ve  and  would  tend  to  relieve  either  AFSPACECOM  or 
ESD  of  responsibility.  It  brought  the  issue  to  the  attention  of 
the  AFSPACECOM  Deputy  Chief  of  Staff  for  Systems  Integration, 
Maintenance,  and  Support  in  July  1987.  The  following  division 
of  labor  between  ESD  and  AFSPACECOM  was  then  defined.  (32:27 
September  87) 

The  ESD  Program  Office  would  be  responsible  for  all 
Granite  Sentry  new  development.  ESD  would  purchase  equipment, 
write  software  through  the  AFSPACECOM  software  house,  and  be 
responsible  for  the  Granite  Sentry  side  of  any  interface  to 
existing  systems.  AFSPACECOM  would  be  responsible  for  coding. 
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testing,  and  implementing  inter-faces  -from  Granite  Sentry  to  the 
existing  systems.  Finally,  equipment  associated  with  the 
operational  system,  such  as  communications  gear,  which  would  be 
UEed  in  various  stages  o-f  the  program,  would  be  managed  by 
AFSPACECOM.  The  Deputy  SPO  Director  in  Colorado  Springs 
represented  the  Program  Director  in  all  but  schedule  decisions. 
This  division  assigned  responsibility  to  the  agency  best  able  to 
handle  the  task.  (29:49)  The  AFSPACECOM  software  effort  was  to 
be  matrixed  via  a  specialised  software  development  division 
dedicated  to  Granite  Sentry.  That  division  would  also  perform 
the  configuration  management  required  for  the  software  effort. 

Unfortunately,  the  40  programmers  were  not  available  in 
January  1987.  (29:50)  Although  it  needed  at  least  10-to-15 
programmers,  only  three  had  been  assigned  on  a  part  time  basis 
by  March.  (33:5)  Consequently,  Government  Services 
Administration  (GSA)  programmers  were  hired  to  carry  out  the 
required  Phase  I  design.  This  was  suboptimal  from  the  point  of 
view  of  program  management  since  it  was  likely  that  the  GSA 
contract  would  terminate  in  October  1988,  leaving  the  program 
without  the  experienced  personnel  who  started  the  design. 
Further,  the  GSA  contract  did  not  require  Ada  language 
programming  experience,  and  the  programmers  had  to  be  trained. 

To  stabilize  the  workforce,  AFSPACECOM  engaged  in  a  separate 
contracting  effort  to  obtain  Ada  software  developers. 

By  the  time  the  GSA  programmers  were  arriving  in 
strength,  AFSPACECOM  freed  16  programmers  to  begin  working  Phase 
I.  The  entire  team  arrived  in  May  1987  and  began  writing  speci- 
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fi cations  -for  a  system  design  review  June.  Since  -few  were 
trained  on  the  systems  software  or  on  Ada,  the  June  design  was 
inadequate.  (34s 1)  The  month  of  July  was  spent  in  training,  and 
internal  milestones  were  adjusted. 

By  autumn  1987,  the  lack  of  Phase  II  software  manpower 
was  critical.  The  problem  was  briefed  to  the  ESD  and  AFSPACECOM 
Vice  Commanders  at  the  November  Senior  Review  Group.  Major  Gen¬ 
eral  Brandt,  the  ESD  Vice  Commander,  formally  complained  of  the 
resource  problem  to  Major  General  Spraker,  the  AFSPACECOM  Vice 
Commander.  As  a  result  of  their  discussion,  the  Granite  Sentry 
Development  Office  (GSDO)  was  formed  and  assigned  to  the 
AFSPACECOM  Vice  Commander.  The  software  personnel  were  still 
matrixed,  but  their  reporting  chain  was  changed  to  assign  them 
functionally  to  the  GSDO.  The  total  number  of  Air  Force 
personnel  committed  to  Granite  Sentry  was  reduced  to  25  because 
of  AFSPACECOM 's  other  commitments  including  427M  software 
maintenance.  (35:1) 

Contracting  problems  slipped  the  AcJa\  software  contract 
award  to  March  1988,  placing  Phase  I  and  Phase  II  further 
behind.  Resources  who  should  have  been  coding  in  January  were 
still  in  training  in  June.  Phase  I  had  lost  a  total  of  246 
man-months,  and  Phase  II  was  behind  by  129  man-months.  (36 j 7) 

As  a  result  of  the  slow  progress,  Phase  II  limited  its 
prototyping  efforts  to  displays,  and  Phase  I  concentrated  on 
coding  rather  than  integration.  The  whole  phasing  sequence 
suffered  because,  in  an  attempt  to  make  up  the  lost  effort,  the 
Phase  I  designers  were  kept  on  Phase  I  instead  of  transitioning 
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to  Phase  II  design  as  the  original  concept  dictated.  However, 
keeping  Phase  I  on  schedule  was  important  to  both  ESD  and 
AFSPACECOM,  and  the  resource  was  applied  there  rather  than  on 
Phase  II. 

While  CINC  NORAD  had  agreed  upon  the  Granite  Sentry  'con¬ 
cept,  the  users  were  skeptical.  Their  uncertainty  manifested  in 
427M  software  changes  which  NORAD  and  the  AFSPACECOM  software 
maintenance  house  believed  were  needed  in  order  to  keep  the 
operational  system  current  and  to  hedge  against  possible  Granite 
Sentry  Phase  I  failure.  These  changes  necessitated  rewriting 
approximately  15,000  lines  of  Granite  Sentry  code,  which 
absorbed  much  of  the  effort  that  months  of  overtime  had  been 
able  to  recover  and  which  contributed  to  the  eventual  Phase  I 
slip.  (37)  To  persuade  NORAD  that  Granite  Sentry  was  committed 
to  deliver  a  useful  system,  two  things  needed  to  happen.  First, 
as  with  bringing  427M  on  line,  the  changes  to  the  existing 
systems  needed  to  be  minimized.  (38:40)  Second,  the  user  needed 
to  become  very  involved  with  its  development.  In  a  large  step 
of  faith,  the  SPO  and  the  GSDO  resolved  to  keep  the  development 
open,  allowing  the  user  access  to  the  programmers  and  system 
whenever  possible. 

NORAD  did  become  extremely  involved  in  the  display 
system  and  in  software  demonstration-  .  Generals  Bourgeois, 
Andrus,  and  Reed  spent  a  great  deal  of  time  refining  the  display 
requirements.  CINC  NORAD  approved  the  Phase  I  displays  in  June, 
1988  and  the  Phase  II  displays  in  March,  1989.  The  software 
demonstrations  convinced  NORAD  personnel  that  Granite  Sentry's 
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goal  was  a  satisfied  user  because  the  coders  were  often  able  to 
accommodate  changes  to  the  system  in  response  to  their 
suggestions.  The  demonstrations  also  convinced  the  programmers 
that  the  user  needed  the  product  and  cared  -for  it  as  a  system 
rather  than  as  a  set  of  specifications.  However,  the  user 
tended  to  fine  tune  the  system  before  it  was  finished,  leading 
to  some  animated  discussions  about  schedules  and  deadlines. 

User  involvement  accomplished  the  goal  of  increasing  user 
support,  and  it  illustrated  the  value  of  the  flexible 
evolutionary  approach.  <3j19> 

User  involvement  also  reduced  program  cost.  For 
example,  the  specification  required  that  data  for  all  missile 
launches  be  available  for  display,  but  it  did  not  state  the 
timeliness  criteria  for  the  term  "available  for  display."  A 
strict  interpretation  could  have  led  to  purchasing  more 
communications  gear  and  much  larger  workstations  in  order  to 
meet  the  tightest  display  times.  At  a  feasibility  briefing, 
NDRAD  representati ves  observed  that  after  a  certain  point  only 
summary  information  was  necessary  and  asked  for  the 
implementation  of  summary  reporting.  (39)  As  long  as  the 
individual  events  were  available  somewhere  in  the  system  and 
were  retrievable  within  a  stated  time  frame,  only  summary 
information  required  immediate  availability.  (39) 

Thus,  from  the  beginning,  Granite  Sentry  Phase  I  imple¬ 
mented  the  principles  of  evolutionary  development,  military 
management,  a  teamed  SPQ  with  both  ESD  and  AFSPACECGM 
responsible  for  success,  collocation  of  a  deci  .ion-making 


portion  of  the  5P0  with  the  developer  and  user,  and  intimate 
user  involvement.  The  evolutionary  approach  demonstrated  its 
ability  to  incorporate  new  requirements  with  the  user 
determining  the  delivery  schedule. 

The  final  factor  which  contributed  to  success  of  425L 
and  427M  was  the  assignment  of  the  user  or  SPO  organisations  to 
high  command  levels.  Such  assignment  did  not  occur  initially  in 
Granite  Sentry.  Manpower  shortages  and  lack  of  support  were 
chiefly  responsible  for  the  failure  of  Phase  1  to  reach  IQC  in 
December,  198S.  Once  the  manpower  and  support  problems  were 
addressed  by  forming  the  GSDO  and  assigning  it  to  the  AFSPACECQM 
Vice  Commander,  the  Phase  I  project  made  excellent  progress. 
Phase  I  Wt<s  turned  oyer  to  test  at  the  end  of  February  1989,  and 
it  reached  IOC  on  March  16th.  Considering  that  the  real 
development  did  not  begin  until  July  1987,  the  24-month  Phase  I 
project  was  implemented  after  only  a  20-month  programming 
effort. 

The  Phase  II  missile  warning  effort  started  late  because 
the  design  team  was  not  assigned  to  Phase  II  on  time.  Until 
July  1989,  personnel  who  should  have  been  designing  Phase  II 
were  still  assisting  the  Phase  I  team  with  the  final  ADOC 
release.  By  this  time,  however,  NORAD  had  become  a  strong 
supporter  of  Granite  Sentry  and  prioritised  both  ADOC  and 
missile  warning  requirements.  It  remains  to  be  seen  whether 
Phase  II  and  subsequent  phases  can  recover  from  the  Phase  I  slip 
which  was  due  to  the  initial  lack  of  resources. 
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CHAPTER  VII 


CONCLUSIONS  AND  RECOMMENDATIONS 

The  Cheyenne  Mountain  system  acquisitions  have  historic¬ 
ally  been  chaotic  and  troubled.  Traditionally,  the  user  has  not 
been  involved  with  new  systems  until  it  is  too  late  to  correct 
problems  easily.  As  with  other  acquisitions  Tor  the  Department 
of  Defense,  these  programs  have  suffered  from  changing  require¬ 
ments  and  specifications  which  are  beyond  the  state  of  the  art. 
The  extremely  capable  software  maintenance  organisation  has  been 
able  to  transform  the  system  being  replaced  so  that  it  sometimes 
surpassed  the  operator's  vision  of  the  replacement  system.  The 
traditional  contract  structure  has  also  hindered  Cheyenne  Moun¬ 
tain  programs.  It  is  nearly  impossible  to  write  a  specification 
for  a  one-of-a-kind  system  planned  for  turnover  years  later. 

The  user's  real  future  requirements  are  difficult  to  predict, 
and  the  user's  needs  change  due  to  software  maintenance, 
impacting  the  contracted  baseline.  With  no  intermediate  system 
to  deliver,  the  program  office  must  renegotiate  contracts  to 
meet  new  requirements,  the  schedule  is  slipped,  and  the  process 
begins  anew. 

Problrm  resolution  has  been  deliberate  and  slow  to  act, 
rarely  reaching  the  correct  decision  in  time  t.o  have  positive 
effects  on  programs.  As  problems  were  encountered  in  each 
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stage,  intervention  by  senior  military  or  civilian  officers  was 
necessary  to  get  the  programs  to  operational  capability.  For 
the  original  NOCOPS,  senior  involvement  was  instrumental  through 
the  Cheyenne  Mountain  Cample::  Task  Force;  -for  427M,  the 
Independent  Review  Group;  and  for  the  early  Cheyenne  Mountain 
Upgrades,  the  General  Accounting  Office.  Each  of  these  groups 
recognised  the  problems  and  recommended  specific  actions  to 
resolve  them.  These  principles  were  incorpora  ed  into  the 
Granite  Sentry  agreement,  and  except  for  resource  problems,  the 
principles  were  vindicated  in  the  Granite  Sentry  Phase  I 
acquisition. 

The  fallowing  principles  influenced  Granite  Sentry  Phase 
I  success:  an  evolutionary  acquisition  strategy,  a  teamed  ap¬ 
proach  with  ESD  and  AFSPACECQM  sharing  responsibility  for 
success  or  failure,  a  decision-empowered  SPO  Deputy  Director 
collocated  with  the  user  and  developer,  a  user  intimately 
involved  with  the  development,  and  an  AFSPACECOM  Granite  Sentry 
Development  Office  managed  by  the  military. 

The  evolutionary  acquisition  approach  focused  the 
program  on  implementing  limited,  single  phases  with  short 
development  cycles  rather  than  a  large-scale,  long-term 
development.  The  short  development  cycle  minimised  the  affect 
of  427M  maintenance  software  releases  on  the  Phase  I  development 
and  allowed  Phase  I  to  maintain  parity  with  the  operational 
system.  The  evolutionary  approach  controlled  current 
requirements  growth  by  providing  opportunity  for  new 
requirements  in  later  phases.  It  allowed  a  working  system  to  be 
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used  in  the  operational  environment-  The  two-year  phase  cycle 
was  short  enough  to  minimize  both  manager  and  developer 
turnover ,  reducing  the  loss  of  corporate  knowledge.  Knowledge 
of  senior  staff  interest  in  the  project  inspired  the  programmers 
and  managers  to  produce  a  successful  project,  and  productivity 
was  maintained  at  a  high  level. 

From  the  beginning  of  the  agreement,  the  ESD  program 
office  demonstrated  its  commitment  to  produce  a  solid  product 
for  NQRAD  on  AFSPACECOM's  schedule.  Collocating  the  deputy 
program  manager  and  staff  with  the  developers  in  Colorado 
Springs  streamlined  the  decision-making  process  as  it  had  for 
the  earlier  CMCMO.  There  was  little  significant  disagreement 
between  the  Granite  Sentry  Development  Office  and  the  Program 
Office. 

User  involvement  was  crucial.  Prototyping  provided  the 
opportunity  for  early  hands  on  experience,  allowing  the  user's 
input  to  make  a  difference  in  the  delivered  product.  The 
delivery  cycle  was  short  enough  that  the  user  who  approved  the 
specification  for  a  phase  saw  the  delivered  system,  enhancing 
NORAD's  desire  to  participate.  The  impact  of  NORAD's 
involvement  in  the  teamed  workforce  cannot  be  overstated. 

The  Granite  Sentry  Development  Office  became  the  focal 
point  for  AFSPACECOM  after  the  office  was  assigned  to  the  Vice 
Commander.  As  with  the  final  427M  and  CMCMO  organizations,  when 
the  vice  and  the  general  staff  demonstrated  interest  in  the  pro¬ 
gram's  success  and  became  intimately  involved,  the  rest  of  the 
staff  followed  suit  and  progress  was  made.  The  single  organiza- 
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tion  -for  implementation  placed  much  responsibility  on  the  de¬ 
velopment  office,  but  allowed  the  -freedom  to  deal  with  the  staff 
and  to  make  rapid  decisions.  The  contractual  structure  allowed 
military  management  to  focus  the  contractors  rapidly  without  the 
delay  of  contract  renegotiations. 

The  synergy  and  balance  afforded  by  the  above  factors 
made  the  implementation  of  the  Air  Defense  Operations  Center  a 
success.  Without  any  one  of  them,  ADOC  could  easily  have  joined 
the  ranks  of  other  troubled  Cheyenne  Mountain  programs.  Should 
any  of  the  factors  change  signif icantly ,  AFSPACECOM  and  ESD 
should  again  meet  at  senior  levels  to  ensure  that  a  correct 
balance  is  again  struck. 

A  single  integration  organization  with  decision 
authority  for  Cheyenne  Mountain  should  be  appointed.  The 
organization  should  have  power  to  immediately  address  and  direct 
solution  of  Cheyenne  Mountain  integration  problems.  It  should  be 
composed  of  both  ESD  and  AFSPACECOM  personnel .  To  not  take 
action  is  to  ignore  the  lessons  of  the  past  24  years  and  three 
major  projects. 

The  negative  influence  of  current  system  software 
maintenance  changes  needs  to  be  controlled.  NORAD  and 
AFSPACECOM  should  take  a  stronger  stand  to  control  change.  The 
maintenance  organization  would  still  be  used  for  emergency 
software  work,  but  should  concentrate  on  influencing  the  new 
systems  before  it  assumes  maintenance  responsibility  of  a 
problem  at  IOC.  Last,  the  other  programs  and  their  eventual 
replacements  should  be  organized  in  an  evolutionary  development 
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structure.  No  specification  is  perfect  and  no  user  can  ever  be 
expected  to  truly  know  what  he  wants  until  he  sees  what  he  gets. 
Acquisitions  should  first  deliver  an  achievable  basic  system 
followed  by  controlled  software  and  hardware  enhancement  with 
user  involvement  in  an  evolutionary  approach.  This  is  the 
optimal  vehicle  for  ensuring  that  the  user  gets  what  he  needs  to 
carry  out  the  vital  NQRAD  mission. 
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GLQSBARY 


ADCDM 

- 

Aerospace  Defense  Command 

ADOC 

- 

Air  Defense  Operations  Center 

AFSC 

- 

Air  Force  Systems  Command 

AFSPACECOM 

- 

Air  Force  Space  Command 

BMEWS 

- 

Ballistic  Missile  Early  Warning  System 

CCPDS 

- 

Command  Center  Processing  and  Display  System 

CCPDSR 

- 

CCPDS  Replacement 

CINC 

- 

Commander  in  Chief 

CMC 

- 

Cheyenne  Mountain  Complex 

CMCFTR 

- 

CMC  Final  Technical  Review 

CMCMO 

- 

Cheyenne  Mountain  Complex  Management  Office 

CMU 

~ 

Cheyenne  Mountain  Upgrades 

COC 

- 

Combat  Operations  Center 

CSS 

- 

Communications  System  Segment 

CSSR 

- 

CSS  Replacement 

DIP 

- 

Display  Information  Processor 

DQD 

- 

Department  of  Defense 

ECP 

- 

Engineering  Change  Proposal 

EOC 

- 

Equivalent  Operational  Capability 

ESD 

- 

Electronic  Systems  Division 

GAD 

- 

United  States  General  Accounting  Office 

GSA 

- 

Government  Services  Administration 

GSDO 

- 

Granite  Sentry  Development  Office 

IDHS 

- 

Intelligence  Data  Handling  System 

IOC 

- 

Initial  Operational  Capability 

IRG 

- 

Independent  Review  Group 

MEBU 

- 

Minimum  Essential  Back  Up 

MWBP 

- 

Missile  Warning  By  Pass 

NCCS 

- 

NORAD  Command  and  Control  System 

NCP 

- 

NORAD  Command  Post 

MCS 

- 

NORAD  Computer  System 

NCSR 

- 

NCS  Replacement 

NOCOPS 

- 

NORAD  Combat  Operations  System 

NORAD 

- 

North  American  Aerospace  Defense  Command 

SAC 

- 

Strategic  Air  Command 

see 

- 

Space  Computational  Center 

SPADOC 

- 

Space  Defense  Operations  Center 

SPO 

- 

System  Program  Office 

SSC 

- 

Space  Surveillance  Center 

USAF 

- 

United  States  Air  Force 

USSPACECOM 

- 

United  States  Space  Command 

WWMCCS 

- 

World  Wide  Military  Command  and  Control  System 

425L 

- 

NOCOPS 

427M 

- 

Cheyenne  Mountain  Improvement  Program 

496L 

- 

Space  Defense  Computational  System 

42 


REFERENCES 


1.  Carrel  ,  John  T.  "A  Choice  of  Roads  to  Defense  Procurement 

Re-form.  "  Air  Force  Magazine, 

September  1989,  pp.  26-29. 

2.  Tomassini,  Lawrence  A.  and  Grudnitski,  Gary.  "Coping  with 

Hindsight  Bias  in  a  Project."  Journal  of  Systems 
Management .  August  1980,  pp. 22-29. 

3.  Roberts,  Alan  J.  "Some  Software  Implications  of  C13  System 

Acquisition."  Si  anal .  July  1982,  pp.  19-25. 

4.  Hirsch,  Edward,  BG  et.  al .  "Evolutionary  Acquisition:  an 

Alternative  Strategy  for  Acquiring  Command  and  Control 
(C=)  Systems."  Defense  Systems  Management  College, 
Fort.  Bel  voir,  Virginia,  March  1987. 

5.  Air  Force  Systems  Command  Detachment  2.  Program  Manager  ' s 

Handbook ,  October  1985. 

6.  United  States  Air  Force  Systems  Command.  "Cheyenne 

Mountain  Complex  (CMC)  Final  Technical  Review." 

Hanscom  Field,  Bedford  MA,  May  1966. 

7.  NORAD  History  Office.  "NORAD's  Underground  COC  -  Initial 

Requirements  to  Initial  Operations  (1956  to  1966)." 

Ent  AFB,  Colorado. 

8.  Memorandum  by  Mr.  Jacobs,  ESD/CCS  staff  member  to  Col 

Congdon,  ESD/CCS.  Subject:  Analysis  of  Winter  Study 
Report,  5  January  1961. 

9.  History  of  the  Electronic  Systems  Division,  Air  Force 

Systems  Command,  1  January-31  December  1965,  Volume  I 
(SECRET),  page  60.  (UNCLASSIFIED). 

10.  United  States  General  Accounting  Office.  "NORAD's  Informa¬ 

tion  Processing  Improvement  Program — Will  It  Enhance 
Mission  Capability."  (LCD-78-117),  21  September  1978. 

11.  Whittaker,  Jonathan  W.  "A  Study  into  Problems  of  a  Major 

Command,  Control,  and  Communications  <C3)  System 
Acquisition."  Research  paper,  Air  Command  and  Staff 
College,  Maxwell  AFB  AL,  May  1980. 


43 


12.  History  of  the  Electronic  Systems  Division,  Air  Force 

Systems  Command,  1  July  1971-30  June  1972,  Volume  I 
(SECRET),  page  85.  (UNCLASSIFIED). 

13.  Druts ,  Aaron.  "427M:  A  Contractor's  View  of  Lessons 

Learned."  IEEE  Journal .  July  1978,  pp.  1327-1332. 

14.  History  of  the  Aerospace  Defense  Command,  1  January-31 

December  1976,  Volume  I  (SECRET),  pp.  64-65. 
(UNCLASSIFIED) . 

15.  Brooks,  Frederick.  The  Mythical  Han  Month:  Essays  on 

Software  Engineering.  Reading,  Massachusetts: 
Addison-Wesley,  1978. 

16.  Hart,  Gary  and  Goldwater,  Barry.  "Recent  False  Alerts  from 

the  Nation's  Missile  Attack  Warning  System."  House 
Armed  Services  Committee  Print,  9  October  1980. 

17.  United  States  General  Accounting  Office,  "Attack  Warning: 

Better  Management  Required  to  Resolve  NORAD 
Integration  Deficiencies."  (GAO/IMTEC-89-26) , 

July  1989. 

18.  Program  Management  Directive  for  Cheyenne  Mountain  Upgrade 

(CMU)  Programs,  (PMD  No.  92747 ( 1 ) /0102310F) ,  5  May 
1989. 

19.  United  States  General  Accounting  Office.  "Attack  Warning: 

NORAD's  Communication  System  Segment  Replacement 
Program  Should  Be  Reassessed.”  (GAO/IMTEC  89-1), 
November  1988. 

20.  United  States  General  Accounting  Office.  "Space  Defense: 

Management  and  Technical  Problems  Delay  Operations 
Center  Acquisition."  (GAO/IMTEC  89-18),  April  1989. 

21.  Enslow,  Phillip  H.  et.  al .  "Summary  Report  of  the  Ad  Hoc 

Technical  Review  Committee  Regarding  the  NORAD 
Cheyenne  Mountain  Complex  Upgrade," 

16  September  1982. 

22.  Staff  Summary,  Brig  Gen  Kelly,  Assistant  Deputy  Chief  of 

Staff,  Plans  to  Lt  Gen  Kutyna,  Commander,  AFSPACECQM. 
Subject:  Written  Inputs  to  GAO  on  CSS/CSSR  Functional 
Comparisons.  20  June  1988, 

23.  Staff  Summary,  Col  James  Strub,  Chief  of  Cheyenne  Mountain 

Development,  to  SPACECOM  Commander.  Subject: 
Integration  Decisions.  16  August  1983. 


44 


24.  Staff  Summary,  Maj  General  Beer,  Headquarters  NORAD/ J5,  to 

NORAD  Vice  Commander.  Subject:  NORAD  Computer  System 
Replacement.  5  May  1983. 

25.  Letter,  Maj  Gen  Beer,  Headquarters  SPACECOM  Deputy  Chief  of 

Staff  Plans,  to  Headquarters  SPACECOM,  Deputy  Chief  of 
Staff,  F'ersonnel .  Subject:  Manpower  Auirhorizations- 
29  June  1983. 

26.  Memorandum  for  Record,  Capt  Shively,  Space  Command 

Directorate  of  Missile  Warning,  Command  and 
Control,  and  Surveillance.  Subject:  NCCS  Discussions 
with  Air  Staff.  1  February  1984. 

27.  Point  Paper,  Space  Command  Deputy  Chief  of  Staff,  Plans  to 

Gen  Herres,  CINC  NORAD.  Subject:  Granite  Sentry 
Program.  15  April  1985. 

28.  Statement  of  Need  for  the  Granite  Sentry  Program  for  the 

Cheyenne  Mountain  Complex,  19  July  1985. 

29.  United  States  Air  Force  Electronics  Systems  Division. 

"Program  Management  Plan  for  the  Granite  Sentry 
Program. "  30  June  1987. 

30.  United  States  Air  Force  Space  Command/XPWC.  "Granite 

Sentry  Program  Briefing. "  November  1986. 

31.  Letter,  Air  Force  Space  Command  Directorate  of  Missile 

Warning,  Surveillance,  and  Command  and  Control 
Systems,  to  Air  Force  Space  Command  Manpower. 

Subject:  Granite  Sentry  Authorizations. 

15  August  1986. 

32.  Granite  Sentry  Program  Log  (Unofficial  Record  of  Phase  I 

and  the  NORAD  Command  Post  Project) ,  Peterson  AFB  CO, 
August  1986-January  1988. 

33.  Electronic  Systems  Division  Granite  Sentry  Program  Office. 

"Granite  Sentry  Management  Information  Summary," 
Hanscom  AFB,  MA.  December  1988. 

34.  Electronic  Systems  Division  Granite  Sentry  Program  Office. 

"Minutes  of  the  Granite  Sentry  Phase  I  System  Design 
Review."  10  June  87. 


45 


35. 


Letter,  Maj  Gen  Spraker,  Mice  Commander,  Air  Force  Space 
Command,  to  Air  Force  Space  Command  Staff.  Subjects 
Formation  of  the  Granite  Sentry  Development  Office. 

10  January  19B8. 

36.  Electronic  Systems  Division  b  ^nite  Sentry  Program  Office. 

"Granite  Sentry  Management.  Information  Summary,." 
Hanscom  AFB ,  MA. ,  July,  1989. 

37.  HQ  Air  Force  Space  Command  Directorate  of  Missile  Warning, 

Survei  1  lance,  arid  Command  and  Control.  "Granite 
Sentry  Monthly  Status  Briefing,"  January  1989. 

38.  James,  Daniel.  "C4  in  NORAD. "  Si qnal ,  September  1977, 

pp.  14-40. 

39.  Briefing,  HQ  Air  Force  Space  Command  Granite  Sentry 

Development  Office  to  Brig  Gen  Andrus,  HQ  NORAD  Deputy 
Chief  of  Staff,  Plans.  Subject:  Granite  Sentry  Phase 

11  Discrete  vs  Aggregrate  Information, 

18  January  1989. 

40.  Detachment  10,  Electronic  Systems  Division,  Cheyenne 

Mountain  Complex  Management  Office,  "Basic  NORAD  COC 
Project  425L/496L  Category  I/Category  II  Equipment 
Test  Report. "  28  September  1965. 

41.  History  of  the  Electronic  Systems  Division,  Air  Force 

Systems  Command,  1  January-31  December  1967,  Volume  I 
(SECRET),  pp.  64-75.  (UNCLASSIFIED). 

42.  History  of  the  Electronic  Systems  Division,  Air  Force 

Systems  Command,  1  January-31  December  1966,  Volume  I 
(SECRET),  pp.  43-44.  (UNCLASSIFIED). 

43.  Program  Management  Directive  for  the  Granite  Sentry 

Program,  (PMD  5244 (4) /1012310F) ,  22  July  1987. 


46 


